1. Field of the Invention
This invention relates to subsystems communications and more particularly to a bus contention control system that detects and responds to excessive bus current most often resulting from attempts by communicating subsystems to contemporaneously drive the same communications bus-lines.
2. Discussion of the Prior Art
Computers and other systems in which information is electrically communicated among primary system elements ("subsystems") typically utilize busses for such communication. Each bus is typically divided into functional sub-groupings ("sub-busses") and each sub-bus further comprises a number of electrical connections ("bus-lines") which directly or indirectly connect two or more subsystems.
Various interconnection configurations ("topologies") for connecting multiple subsystems using one or more serial and/or parallel busses are well known in the art, as are the use of separate ("non-multiplexed") or shared ("multiplexed") address and data bus-lines. For purposes of illustration, the term "bus" will refer to a parallel, multiplexed or non-multiplexed bus in which subsystems connect to designated bus-lines of a continuous linear trunk, commonly referred to as a linear bus topology model.
FIG. 1 shows, for example, a bus ("PC bus") 101 as it is commonly used in a conventional personal computer ("PC") 100. Connected to PC bus 101 in a typical configuration are processor 120, memory 130, host video I/O controller 140, host audio I/O controller 150, user-I/O controller (for connecting user interface control devices such as a keyboard and/or mouse) and system expansion interface 170. PC bus 101 provides a common communications pathway for transfer of commands and data among all connected subsystems. While deviations exist, such as the monitor 145 connection to host video I/O controller 140, the predominant model remains that of a linear bus. Similarly, the host video I/O controller 140 and monitor 145 pair and other subsystems might be connected to system expansion interface 170 forming a secondary linear bus without need to redefine the predominant linear bus model.
Communicating subsystems communicate over a bus by setting the signal level of designated bus lines to appropriate states at predetermined times according to a predetermined procedure or "protocol." For example, subsystems communicate over a digital bus by setting the voltage of, or "driving", selected bus-lines to a higher or lower level (according to the regular pulses of a clock) using one or more integral subsystem bus drivers. Typically, an originating subsystem ("sender") initiates a message for receipt by an intended receiving subsystem ("receiver"). Since all present and activated subsystems on the bus will receive all bus communications, each subsystem is assigned a unique designation ("address") and each communication is preceded by the intended receiver's address. Upon receipt, each receiver compares the intended receiver's address against its own. A receiver with a matching address further considers the communication, responds, sends data and/or receives data according to the protocol utilized and the contents of the communication received.
Conventional bus structures, as described thus far, are well matched to the needs of conventional systems, such as personal computers ("PCs"). The Personal Computer Interface ("PCI") bus, for example, is well matched to the moderate communication rates and limited number of operationally static subsystem expansions and modifications available in conventional PCs. For example, the PCI bus, as commonly configured, provides a transfer rate of only fifty megabytes per second. While subsystem-receiving sockets ("slots") are provided for adding and exchanging add-on subsystems ("expansion cards"), only three such slots are typically provided. In addition, expansion cards provide wholly predictable interaction with the bus and other system components. Expansion cards are assigned an address upon installation and their functionality, their communications pattern and their respective addresses remain essentially unchanged during operation.
The discussed bus structure is also often well matched to a more complex system requiring faster communication and utilizing dynamic subsystem address and bus assignment among a larger number of dynamically reconfigurable subsystems. Unfortunately, such a bus structure does not envision the potentially catastrophic results that might occur in such a complex system if more than one subsystem attempts to utilize the same bus contemporaneously. Such conflicting attempts to utilize a bus are commonly referred to as "bus contention" or simply "contention."
Contention is not a critical concern in PCs and other less complex systems providing only moderate speed communications. One reason is that the possibility of contention is extremely remote in such a "well-behaved" system. Only a small number of statically addressed subsystems must compete for available communications lines and only a moderate communication rate is utilized, thus decreasing the probability that error will occur. In addition, such systems are not required to perform responsively enough to be considered real-time and, as a result, bus allocation according to a simpler predetermined priority-level based, "first-come first-serve" method can be imposed with little concern for time-intensive subsystem communications that might monopolize bus usage. Sufficient controls can therefore more readily be applied to prevent nonparticipating subsystems from interfering with ongoing communications. Thus, the potential causes of contention are nearly non-existent.
A second reason is that, even if contention should occur, the results of contention in such less complex systems, while undesirable, are not catastrophic. In such a case, only an unfortunate corruption of data (due to conflicting information being placed on a bus at the same time) might occur. Since data corruption can also occur for any number of other reasons, such as line noise, methods are well known for detecting and correcting corrupted data transmissions. In addition, the extended time required for such detection and correction, which typically amounts to checking received data and requesting re-transmission, is of little consequence in a non-real-time system. Thus, neither a rare occurrence of contention nor conventional time-intensive corrective measures pose an immediate threat to overall system integrity in PCs or other such less complex and well-behaved systems.
Unfortunately, more complex systems with higher communication rates are more prone to contention and other errors, so conventional time-intensive prevention and corrective measures cannot be readily employed, particularly in real-time systems. To make matters worse, such errors might well produce catastrophic results. Faster communication over a bus requires faster switching, which, due to lower bus impedance, requires bus drivers capable of delivering greater current. Should contention occur, it is likely that, at some point, one contending subsystem will attempt to drive one or more bus-lines low while another attempts to drive the same bus-lines high. In such a case, the subsystem attempting to drive the bus-lines high has a sufficient source of current available that the subsystem will deliver ever-increasing amounts of current to the bus-lines in its effort to drive the bus-lines high. Likewise, the subsystem attempting to drive the bus-lines low will continue to sink the ever-increasing bus-line current, potentially resulting in both cases in dangerous current levels. Thus while occurrences of contention are rare, detection and corrective actions should be provided and such actions should be quickly and reliably implemented. Conventional time-intensive data corruption tests and potential re-transmission are therefore wholly inadequate, particularly among faulty systems that produced the error utilizing the communication path that has already been put at risk.
Thus, there is a need for a means for quickly detecting, responding to, and avoiding a continuing occurrence of bus contention.